1. Field of the Invention
The invention relates in general to communications over computer networks, and more particularly, to remote login from one computer to another.
2. Description of the Related Art
The standard model for network applications is the client-server model. A server process is a process that waits to be contacted by a client process for which the server process performs some function. A typical scenario, for example, might involve a server process starting on some computer system in a network. The server process initiallzes itself, then goes to sleep waiting for a client process to contact it requesting some service. A client process is started on another computer connected to the server computer by the network. The client process sends a request across the network to the server requesting some form of service. The server responds by performing the requested service such as: print a file for the client, read or write a file on the server system and deliver it to the client, execute a command for the client on the server system, or allow the client to login to the server system.
The last mentioned function, allowing a user of a client system to login to the server system, can permit a user to enter instructions to the client and have those instructions executed by a server system. In this manner, it is possible for the user to access information stored in by server system or to utilize the processing power of the server system, for example. A login process ordinarily involves setting up a network connection between a client system and a server system. Establishing a network connection such that a client can issue instructions to a server system typically involves the creation of processes in both the client system and the server system to support the transfer of information, either instructions or data, between the two systems in such a fashion that instructions issued by a user, through the client system control the server system, and so that data provided by the server system is displayed by the client system.
In a UNIX operating system environment, one of the most common approaches to login to a remote system is through the well known xe2x80x9crloginxe2x80x9d (remote login) process. A description of the popular rlogin process is provided in Unix Network Programming, W. Richard Stevens,. Prentice Hall, Inc., 1990, chapter 15, Remote Login, pages 589-667. An exemplary implementation of rlogin will be explained with reference to FIGS. 1A, 1B and 1C. FIG. 1A illustrates the structure and interaction among client side process modules prior to the execution of the rlogin process. FIG. 1B illustrates the structure and interaction among client side process modules following the execution of the rlogin process. FIG. 1C illustrates the structure and interaction among server side process modules following the execution of the rlogin process.
Referring to FIG. 1A, before rlogin is invoked, a user communicates directly with the client system through a shell program 20 created in user memory space. The shell program is a command interpreter that users typically execute after logging into the client system. In essence, the shell program receives user input and acts on it. The shell program, for example, may respond to user input by issuing calls to appropriate operating system services that exist in the system kernel memory space. For a general discussion of the UNIX operating system, refer to The Design of the UNIX Operating System, Maurice J. Bach, Prentice -Hall, Inc., 1986. The shell program is discussed at pages 6-15 of that book.
In the UNIX operating system environment, user memory space and kernel memory space ordinarily are separated. Generally, although user memory space ordinarily is occupied by user processes and files, it may be preempted by the kernel. Kernel memory space usually can be occupied only by the operating system kernel unless the kernel gives up the space. As a result, special operating system communications mechanisms have been developed to transfer information (data or instructions) across the user-kernel memory space boundaries. One such mechanism involves xe2x80x9cstreamsxe2x80x9d. In FIG. 1A, a stream-head transfers information between a tty-connection module 24, in kernel space, and the shell program 20, in user space.
A tty-connection allows a process to communicate with an external device such as disks, tape drives, terminals and networks. The kernel modules that control devices are known as device drivers. Terminal drivers have the same function as other drivers: to control the transmission of data to and from terminals. Terminals are the user""s interface to the system. Examples of terminal devices include, keyboard, mouse and display screen. To accommodate interactive use of the UNX system, terminal drivers typically contain an internal interface to line discipline modules, which interpret input and output. For example, in canonical mode, the line discipline converts raw data sequences typed at the keyboard to a canonical form before sending the information to the receiving process. The line discipline also converts raw output data produced by processes into a form the user expects. In raw mode, the line discipline passes data between processes and the terminal without such conversions.
In operation, tty-drivers 26, responsive to user input strokes on a keyboard, for example, communicate with the tty-connection module 24, which in turn, communicates through the stream-head 22 with the shell program 20. The terminal-connection, for example, can be a stack comprising multiple modules that have been individually pushed onto the stream beneath the stream-head 22. The shell 20 interprets the user keyboard input and issues appropriate system calls.
A description of streams in a UNIX operating system environment is provided in, Unix Network Programming, Sections 7.7-7.9, Pages 374-386. A stream is a full-duplex connection between a user process and a device driver or a pseudo-device driver. A typical stream connection includes a set of linearly linked queue pairs, one member of each pair for input and the other for output. The top portion of a stream in the kernel space is referred to as a stream-head and serves as a system call interface. A feature of streams is that a process can add modules between the stream-head and a device driver or pseudo-device driver. Each new processing module is pushed onto the stream just below the stream-head in a LIFO stack. An example of a stream process module is one that implements terminal line discipline. Another example of the use of stream modules is to implement a communication protocol. For example, a device driver may serve as a network interface (Ethernet device driver, token ring device driver, etc.), and a series of linked stream modules may provide a layered network protocol (TCP/IP, XNS, etc.) When a process writes data to a stream, the kernel sends the data down the stream""s output queue. When a device driver receives input data, it sends the data up the stream""s input queue to a reading process. The stream modules operate on the data as the data is passed up and down the stream queues.
Referring to FIG. 1B, when rlogin is invoked, it instantiates a set of software modules that interact to cause the client system to implement a remote login to a server system. More particularly, a client side network-connection 28 is created, in kernel space on the client system, to the server system. The client side network-connection 28 (within dashed lines) communicates with TCP-lower-q 31 (xe2x80x9ctransport control protocolxe2x80x9d) and is linked to a new stream-head 32. The network-connection 28, for example, may include a TCP-upper-q module 27 and a sockmod 29 (xe2x80x9csocket connectionxe2x80x9d). The TCP-upper-q 27 transfers information to and from TCP-lower-q 31 over the network that connects the client and server systems. The current tty-connection state is saved, and the tty-connection is set to the raw mode. An rlogin-r client process 34 is created in user space to read data from the network-connection 28 and write it to the tty-connection 24. An rlogin-w client process 36 is created in kernel space to read data from the tty-connection 24 and write it to the network-connection 28. Stream-head 22 transfers information between the tty-connection 24 in kernel space and the rlogin-r 34 and rlogin-w 36 processes in user space. Stream-head 32 transfers information between the network-connection 28 in kernel space and rlogin-r 34 and rlogin-w 36 in user space.
It should be appreciated that there is an enormous variety of tty types and network types. For example, the tty-connection may include one or more of the following modules: ttcompat (terminal compatibility), ldterm (line discipline), ptem (pseudo-terminal), etc. The tty-drivers, for example, may include serial driver, network connection, network-drivers, etc. The network-connection, for instance, may include socket, TCP, etc. Finally, the network-drivers may consist of IP-driver, Ethernet driver, token-ring driver, FDDI driver, ATIM Fast Ethernet, etc.
The illustrative drawing of FIG. 1C shows an example of possible server system software-based structures and module interactions that result when the client invokes rlogin. First, second and third server side stream-heads 40, 42 and 44 are created in the server system kernel memory space. The in.rlogind process 38 is created in the server system user memory space. in.rlogind is a single process which operates to multiplex signals transferred between the first and second server stream-heads 40 and 42. The first server stream-head 40 transfers information between in.rlogind and sockmod 46 and TCP-upper-q 48 which are created in server kernel memory space and which are linked in a stack below the first stream-head 40. Note that TCP-upper-q module 48 communicates with the TCP-lower-q 31 as shown. The second server stream-head 42 transfers information between in.rlogind 38 and pckt (packet driver module) 52 and ptm (pseudo-terminal-master module) 54 which are created in server kernel memory space and which are linked in a stack below the second stream-head 42. The third server stream-head 44 transfers information between the shell-server 64 and ttcompat (maintains compatibility with earlier software versions) 56, ldterm (line discipline) 58, ptem (pseudo-terminal emulation module) 60 and pts (pseudo-terminal-slave) 62, which are created in server kernel memory space and which are linked in a stack below the third stream-head 44. Note the linkage between ptm 54, which is a pseudo-terminal driver for rlogind, and pts 62, which is a pseudo-terminal driver for shell-server 64. The server login 66 accepts and verifies the user password, for example.
Referring to FIGS. 1B and 1C, note that the client system employs two processes, rlogin-r 34 and riogin-w 36 to transfer information in two directions rather than using a single multiplexing process like in.rlogind 38 which is created on the server system. One reason for the creation of two client system processes is that it often is desirable to have the ability to stop the rlogin-w process 36 without stopping the rlogin-r 34 process so that the user can halt data transfer from client to server in order to enter commands on the local client system, while still allowing any output from the remote server system to appear on the user""s local client terminal.
The following is a brief description of the client side steps typically involved in transferring a single character from the client system to the user system using the structures illustrated in FIGS. 1B and 1C. The rlogin-w process 36 reads the character from the tty-connection 24 via stream-head 22 and writes it to the network-connection 28 via stream-head 32. The character is transferred to the remote server via a computer network. The server receives the character, and echoes it back to the client system over the computer network. system. The rlogin-r process 34 reads the echoed character from the network-connection 28 via stream-head 32 and writes it to the tty-connection 24 via stream-head 22.
Client system access to a remote server system using the communication structures and processes described above ordinarily requires two client processes per connection (rlogin-r and rlogin-w).
It also requires two client side context switches per character (one per client stream-head). It further requires four client side data copy operations per character (two per stream-head). Unfortunately, the use of two processes requires more memory, and the multiple context switches and data copy operations consume more processor time. The preceding example involved the transfer of only a single character. The client system resource utilization problems can compound when large number of characters are to be transferred.
It will be appreciated that the problems described above with reference to the exemplary rlogin process also exist in other processes such as telnet and rsh, for example. Thus, there has existed a need for an improved mechanism for remote login communications between a client system and a server system. The present invention meets this need.
The present invention provides a novel process and computer program based control of a client computer system which effect a remote login session with a server computer system through control mechanisms resident entirely in client kernel memory space. The invention advantageously reduces the number of processes, context switches and data copies required during a remote login session. As a result, less memory and fewer processing resources are required for remote login. These and other features and advantages of the invention will be better appreciated from the following detailed description and the accompanying drawings.